Skip to content

Avoid recomputing tree when a new root node is added #194

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Avoid recomputing tree when a new root node is added #194

wants to merge 1 commit into from

Conversation

@p-r-a-v-i-n
Copy link

@p-r-a-v-i-n p-r-a-v-i-n commented Jun 20, 2025

name: Pull request
about: Avoid recompute of the entire tree when new root node was added.
assignees: fabiocaccamo

Describe your changes
Previously, whenever a new root node (i.e. a node with no parent) was added, the entire tree structure was recomputed. This was redundant and negatively impacted performance.

With this change:

  • Tree recomputation is skipped when a new root node is added, as it does not affect existing nodes.
  • Updated the is_last_child method to return False for nodes with no parent (i.e. root nodes), since they cannot be considered children.
  • Adjusted tests for sibling checks root nodes should have no siblings, so the expected count and list are 0 and [] respectively.

Related issue
closes #45

Checklist before requesting a review
I have performed a self-review of my code.
I have added or updated tests for the proposed changes.
I have run the test suite and confirmed that all tests pass.

@p-r-a-v-i-n
Copy link
Author

p-r-a-v-i-n commented Jun 23, 2025

Hi @fabiocaccamo, when you have some time, could you please review this?

@p-r-a-v-i-n p-r-a-v-i-n force-pushed the fix/optimize-query-performance branch from 8af66cf to b12056d Compare June 24, 2025 05:14
@codecov
Copy link

codecov bot commented Jun 24, 2025 •
edited
Loading

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.21%. Comparing base (df33dbf) to head (24e0b08).

Additional details and impacted files 
@@            Coverage Diff             @@
##             main     #194      +/-   ##
==========================================
+ Coverage   91.14%   91.21%   +0.07%     
==========================================
  Files          11       11              
  Lines         700      706       +6     
==========================================
+ Hits          638      644       +6     
  Misses         62       62
Flag Coverage Δ
unittests 91.21% <100.00%> (+0.07%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@p-r-a-v-i-n
Avoid recomputing tree when a new root node is added
24e0b08 
- Skip tree recomputation when the newly added node is a separate root.
- Updated `is_last_child` to return False for root nodes without children.
- Adjusted tests for sibling count and presence accordingly.
- Commented out unused `get_tree_dump` method.
@p-r-a-v-i-n p-r-a-v-i-n force-pushed the fix/optimize-query-performance branch from b12056d to 24e0b08 Compare June 24, 2025 11:10
@fabiocaccamo
Copy link
Owner

fabiocaccamo commented Aug 30, 2025

@p-r-a-v-i-n the PR should be 100% backward compatible, please do not change existing tests.

@p-r-a-v-i-n
Copy link
Author

p-r-a-v-i-n commented Aug 31, 2025

@fabiocaccamo I can understand your concern.
In the existing the code , lets say if we create new nodes with no common parent . it still consider the them as siblings of each other even if they are the seperate nodes. and this is the reason why it not optimize since it will do the calculation/computing again.

I have change only this part in testing. where I was making sure that nodes can be siblings of each other only if they share common parent if not then they don't have any siblings.

@fabiocaccamo
Copy link
Owner

fabiocaccamo commented Sep 4, 2025

@p-r-a-v-i-n for example I used this library for managing menu items on multiple websites, menu items are considered as siblings, even if they don't share the same parent (or yes, None).
Maybe this has not been the best design choice, but I want to keep 100% backward compatibility.

If you can adapt your changes avoiding to change existing tests I would be happy to merge it!

@p-r-a-v-i-n
Copy link
Author

p-r-a-v-i-n commented Sep 5, 2025

totally fine. but I would still argu that we should go for this approach for long run. this won't impact on anything that exist related to django-tree node.

anyway I will work on it. may be i can find a better approach with backward compatibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Queries getting slower during progress

2 participants

@p-r-a-v-i-n @fabiocaccamo